Business Requirements Document

For

<Project>

Version 1.0

Prepared by <author>

<Date created>

Table of Contents

Table of Contents	1

Revision History	1

Project Team Members	2

1.	Introduction	2

1.1	Purpose	2

1.2	Project Scope	2

1.3	References	2

2.	Overall Description	2

2.1	Business Objectives	2

2.2	Current State	2

2.3	Future State	2

2.4	Systems Impacted	2

2.5	Design and Implementation Constraints	2

2.6	User Documentation	2

2.7	Assumptions and Dependencies	2

3.	Functional Requirements	2

4.	Business Rules	2

5.	External Interface Requirements	2

5.1	User Interfaces	2

5.2	Hardware Interfaces	2

5.3	Software Interfaces	2

5.4	Communications Interfaces	2

6.	Other Nonfunctional Requirements	2

6.1	Performance Requirements	2

6.2	Security Requirements	2

6.3	Software Quality Attributes	2

6.4	Reporting Requirements	2

7.	Other Requirements	2

Appendix A: Glossary	2

Business Requirements Sign off	2

Revision History

Name	Date	Change(s)	Version

Project Team Members

Name	Department/Title	Role	Reviewer/Approver

Introduction

Purpose

<Identify the product whose functional requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this BRD, particularly if this BRD describes only part of the system or a single subsystem.>

Project Scope

<The scope should be taken from the project charter.>

References

<List any other documents or Web addresses to which this BRD refers such as the SharePoint Site, SIPOC, RMP. These may include contracts, standards, system requirements specifications, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.>

A link is preferred to ensure the reader has access to the latest version of the document(s). Provide a link to Vision document produced as output from Concept phase.

Overall Description

Business Objectives

Number	Business Objectives	Owner
BO1.0	<Business Objective 1>	<Name>
BO2.0	<Business Objective 2>	<Name>
BO3.0	<Business Objective 3>	<Name>

<Describe the business objective as a high level need, in business language. For project that had a BA involved in the Concept phase, the business objectives will come from the vision document.>

Current State

< A picture of the major groups/interaction of current process and how they relate, such as a top level data flow diagram is often effective.>

<If not inserted within document, provide a link to the current state flow.>

Future State

< A picture of the major groups/interaction of future process and how they relate, such as a top level data flow diagram is often effective.>

<If not inserted within document, provide a link to the future state flow.>

Systems Impacted

<Listing with descriptions of the systems impacted with the project and the integration points.>

Design and Implementation Constraints

<A constraint is something that may restrict or limit the system in some way. This may give rise to functional requirements and business rules. A constraint may be the platform on which it can be developed, a budgetary restriction, or corporate or regulatory policies. There are likely to be organizational reasons for these, but they are always worth questioning.>

User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>

Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the BRD. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).>

Functional Requirements

Functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do <requirement>.

The business analyst/project manager will facilitate stakeholder meetings in order to establish priorities for all project requirements. This project will use a three-level scale in order to prioritize requirements. The chart below illustrates these levels and defines how requirements will be grouped:

Priority Level	Definition
High (Must Have)	Mission critical. They are required for project success or progression into the next phase.
Medium (Should Have)	Non-core, discretionary functionality that should be deployed but if not ready, deployment would not be delayed.
Low (Nice to Have)	Desirable if time and budget permits.

#	Description	Priority	Owner

Business Rules

A Business Rule is a specific, actionable, testable directive that is under the control of an organization and that support a business policy.

#	Reqt	Description

External Interface Requirements

User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.>

Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>

Software Interfaces

<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.>

Communications Interfaces

<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>

Other Nonfunctional Requirements

Performance Requirements

#	Description	Priority	Owner
The system shall accommodate Production volume of <xx> concurrent users during a peak hour of a peak business day (Maximum number of users logged into the application at the same time during busiest hour of a busiest business day). E.g., 8 AM – to 9 AM on a 1st Monday of the month could be the busiest hour. System admin can provide a trend graph of number of users logged in during this hour.
The system shall accommodate Production volume of <xx> concurrent users during an hour of a normal business day.
The system shall accommodate Production volume of <xx> number of <Business Transaction Name / Service Name> during a peak hour of a peak business day. This row to be repeated for each business transaction / service
The system shall accommodate Production volume of <xx> number of <Business Transaction name / Service Name> on an hour of a normal business day. This row to be repeated for each business transaction / service.
The <Business Transaction Name> transaction should respond within <xx> seconds, (end-to-end response time). This row to be repeated for each business transaction.
<Batch_Job_Name> Batch job running concurrently, should not impact the online users’ performance (no change to the response time SLA as mentioned in REQT -5). This row to be repeated for each of the concurrent batch jobs
The system should be able to handle <xx>% growth Year-On-Year for next <xx> years.
System should be available <xx> hours every day (e.g., 24/7).
The overall system resource utilization for <server name> should not exceed <xx>% of CPU.
The overall system resource utilization for <server name> should not exceed <xx>% of Memory utilization.
The failure rate for a critical <Business Transaction_Name> transaction should not exceed a threshold of <xx>%. This row to be repeated for each of the transactions
90% of the time, Critical <Business Transaction_Name> transaction(s) response times should meet the SLA of <xx> seconds. (With +/- 5% variance). This row to be repeated for each of the transactions. (Guidance)

Security Requirements

#	Description	Priority	Owner

Software Quality Attributes

#	Description	Priority	Owner

Reporting Requirements

#	Description	Priority	Owner

Other Requirements

<Define any other requirements not covered elsewhere in the BRD. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary

<Define all the terms necessary to properly interpret the BRD, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each BRD.>

Business Requirements Sign off

I have reviewed the information contained in this document and agree:

Name	Title	Signature	Date